<html>
<head><meta charset="utf-8"><title>failable allocators and collections · t-libs/wg-allocators · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/index.html">t-libs/wg-allocators</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html">failable allocators and collections</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="167830613"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167830613" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167830613">(Jun 11 2019 at 08:42)</a>:</h4>
<p>Hey all. I've been searching online and trying to find the current state of "failable allocators" (specifically around collections) but I'm coming up empty. I need to be able to gracefully handle OOM errors. What is the current state of being able to do so? Is there a crate that exports the proposed "try" methods for collections (e.g., "try_push" for Vec)? Is it possible to write such a crate without having to reinvent the std lib collection implementations from scratch?</p>



<a name="167831129"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831129" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831129">(Jun 11 2019 at 08:50)</a>:</h4>
<p>There's the mp4parse_fallible crate, which should be updated to use the now stable global allocator functions to reallocate...</p>



<a name="167831175"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831175" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831175">(Jun 11 2019 at 08:51)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/46865#issuecomment-500241534" target="_blank" title="https://github.com/rust-lang/rust/issues/46865#issuecomment-500241534">https://github.com/rust-lang/rust/issues/46865#issuecomment-500241534</a> summarizes the status for fallible allocation and links relevant tracking issues</p>



<a name="167831253"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831253" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831253">(Jun 11 2019 at 08:52)</a>:</h4>
<p><code>try_reserve</code> is in Nightly. Presumably <code>try_push</code> can be implemented as <code>self.try_reserve(1); self.push(x)</code>, and similarly for other methods</p>



<a name="167831306"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831306" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831306">(Jun 11 2019 at 08:53)</a>:</h4>
<p>But on stable yeah, it’s gonna be copy-paste more than reinvent, but still</p>



<a name="167831406"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831406" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831406">(Jun 11 2019 at 08:55)</a>:</h4>
<p>There’s <a href="https://github.com/servo/servo/tree/master/components/hashglobe" target="_blank" title="https://github.com/servo/servo/tree/master/components/hashglobe">https://github.com/servo/servo/tree/master/components/hashglobe</a>, with a weirdly condescending readme</p>



<a name="167831506"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831506" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831506">(Jun 11 2019 at 08:57)</a>:</h4>
<p>Hmmm... surprised no one has tried to come up with a crate that addresses this. Sounds like something the embedded working group would need a solution in the short term for (while waiting for the std implementation to stablize).</p>



<a name="167831615"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831615" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831615">(Jun 11 2019 at 08:59)</a>:</h4>
<p>And RawVec is also unstable so yea... there would be quite a lot of copy/pasting...</p>



<a name="167831675"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831675" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831675">(Jun 11 2019 at 09:00)</a>:</h4>
<p><span class="user-mention" data-user-id="224872">@Ryan Levick</span>  “No one” has tried? We just just pointed out two crates…</p>



<a name="167831705"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831705" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831705">(Jun 11 2019 at 09:01)</a>:</h4>
<p>Well I mean crates without the ominous "don't use this" warnings</p>



<a name="167831714"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831714" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831714">(Jun 11 2019 at 09:01)</a>:</h4>
<p><a href="https://github.com/servo/servo/blob/master/components/fallible/lib.rs" target="_blank" title="https://github.com/servo/servo/blob/master/components/fallible/lib.rs">https://github.com/servo/servo/blob/master/components/fallible/lib.rs</a> is another. It adds <code>Vec::try_push</code> on stable</p>



<a name="167831733"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831733" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831733">(Jun 11 2019 at 09:01)</a>:</h4>
<p>hashbrown has <code>try_reserve</code> on stable: <a href="https://docs.rs/hashbrown/0.4.0/hashbrown/struct.HashMap.html#method.try_reserve" target="_blank" title="https://docs.rs/hashbrown/0.4.0/hashbrown/struct.HashMap.html#method.try_reserve">https://docs.rs/hashbrown/0.4.0/hashbrown/struct.HashMap.html#method.try_reserve</a></p>



<a name="167831750"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831750" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831750">(Jun 11 2019 at 09:01)</a>:</h4>
<p>we should probably move firefox/servo to that instead of hashglobe</p>



<a name="167831874"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167831874" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167831874">(Jun 11 2019 at 09:03)</a>:</h4>
<p>Awesome - so it seems like maybe it wouldn't be to terribly hard to collect these implementations into a crate that provides extension traits for all std lib collections</p>



<a name="167832103"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832103" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832103">(Jun 11 2019 at 09:07)</a>:</h4>
<p>In the hashbrown case the idea would be to use it instead of std HashMap</p>



<a name="167832120"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832120" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832120">(Jun 11 2019 at 09:07)</a>:</h4>
<blockquote>
<p>we should probably move firefox/servo to that instead of hashglobe</p>
</blockquote>
<p>that, or move hashglobe to <code>std::alloc::alloc</code></p>



<a name="167832192"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832192" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832192">(Jun 11 2019 at 09:08)</a>:</h4>
<p>which servo's fallible module would need anyways</p>



<a name="167832218"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832218" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832218">(Jun 11 2019 at 09:08)</a>:</h4>
<p><span class="user-mention" data-user-id="220510">@Mike Hommey</span> You mean stabilizing <a href="https://github.com/rust-lang/rust/issues/48043" target="_blank" title="https://github.com/rust-lang/rust/issues/48043">https://github.com/rust-lang/rust/issues/48043</a> ? IIRC that’s blocked on deciding the error type, but that’s probably solvable</p>



<a name="167832256"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832256" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832256">(Jun 11 2019 at 09:09)</a>:</h4>
<p>No, I mean using <code>std::alloc::alloc</code> and <code>std::alloc::realloc</code> instead of the custom implementations in hashglobe</p>



<a name="167832418"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832418" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832418">(Jun 11 2019 at 09:12)</a>:</h4>
<p>ah ok</p>



<a name="167832556"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832556" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832556">(Jun 11 2019 at 09:13)</a>:</h4>
<p>Am I wrong in thinking that because <code>std::alloc::{alloc,realloc}</code> are stable and all collections expose their capacities and reallocate in known ways, it should be possible to create extensions for all collection types in a stable way?</p>



<a name="167832774"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832774" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832774">(Jun 11 2019 at 09:17)</a>:</h4>
<p>In other words, there are well defined ways to allocate on behalf of a collection and because of this it makes it relatively trivial to check if that allocation failed (i.e., alloc or realloc returned a null pointer).</p>



<a name="167832882"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167832882" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167832882">(Jun 11 2019 at 09:18)</a>:</h4>
<p>for collections that allow to take them apart, yes. That's what the mp4parse_fallible crate does, albeit not using <code>std::alloc::{alloc, realloc}</code> (filed <a href="https://github.com/mozilla/mp4parse_fallible/issues/5" target="_blank" title="https://github.com/mozilla/mp4parse_fallible/issues/5">https://github.com/mozilla/mp4parse_fallible/issues/5</a>)</p>



<a name="167833027"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167833027" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167833027">(Jun 11 2019 at 09:20)</a>:</h4>
<p><code>Vec</code> has <code>as_mut_ptr</code> and <code>from_raw_parts</code>, which would allow that. <code>HashMap</code> doesn't.</p>



<a name="167834107"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167834107" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167834107">(Jun 11 2019 at 09:36)</a>:</h4>
<p>Hmm... I wonder if there's a way to easily translate between a hashbrown HashMap and the std HashMap without reallocating since they're technically the same thing.... That way you could take advantage of hashbrown's ability to reallocate in a failable way</p>



<a name="167834222"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167834222" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167834222">(Jun 11 2019 at 09:38)</a>:</h4>
<p>There’s an easy way: <code>transmute</code>. There is no <em>good</em> way IMO, std’s <code>HashMap</code> deliberately keeps its internal layout private.</p>



<a name="167834276"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167834276" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167834276">(Jun 11 2019 at 09:39)</a>:</h4>
<p>But if you’re taking on a dependency on crates.io’s hashbrown anyway, why not use it instead of std’s HashMap and avoid conversions completly?</p>



<a name="167834319"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167834319" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167834319">(Jun 11 2019 at 09:39)</a>:</h4>
<p>Yea, I don't know enough about the gurantees that hashbrown and std HasMap have to know if they can easily share buffers (so you don't have to rely on transmute)</p>



<a name="167834417"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167834417" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167834417">(Jun 11 2019 at 09:40)</a>:</h4>
<p>simply for type capbility - if user's of the crate can extend std HashMap and use it instead of having to force users of the crate to accept hasbrown as an explicit dependency</p>



<a name="167834447"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167834447" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167834447">(Jun 11 2019 at 09:41)</a>:</h4>
<p>presumably one could try to crate a crate that will eventually just be a thin veil over the newly stablized try_* methods</p>



<a name="167834456"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167834456" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167834456">(Jun 11 2019 at 09:42)</a>:</h4>
<p>you can't do that if you explictly expose hasbrown as part of the public API</p>



<a name="167840441"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167840441" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167840441">(Jun 11 2019 at 11:17)</a>:</h4>
<p><span class="user-mention" data-user-id="219747">@Simon Sapin</span> do you know specifically what is preventing stabilization of failable allocation APIs in collections?</p>



<a name="167841539"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167841539" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167841539">(Jun 11 2019 at 11:37)</a>:</h4>
<p><span class="user-mention" data-user-id="224872">@Ryan Levick</span> I think it’s mostly the error type</p>



<a name="167841619"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167841619" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167841619">(Jun 11 2019 at 11:39)</a>:</h4>
<p>The <code>Layout</code> of the allocation that failed should probably be in there</p>



<a name="167841874"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167841874" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167841874">(Jun 11 2019 at 11:43)</a>:</h4>
<p>And, for when containers containers become generic over the allocator type, do we want the <code>Alloc</code> trait to have an associated error type? If so, <code>CollectionAllocErr</code> should probably be generic to contain that error type (together with the <code>Layout</code>). Or at least have a path so we can add that type parameter without breakage</p>



<a name="167842322"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167842322" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167842322">(Jun 11 2019 at 11:51)</a>:</h4>
<p>Do you see any reason that an rfc shouldn't be able to decide this? ie are there any external issues that would prevent the discussion for reaching a conclusion? If not I might take this on</p>



<a name="167843430"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167843430" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167843430">(Jun 11 2019 at 12:07)</a>:</h4>
<p>It depends. I think the three options are :</p>
<p>1. Propose to block <code>try_reserve</code> on the resolution of <a href="https://github.com/rust-lang/wg-allocators/issues/23" target="_blank" title="https://github.com/rust-lang/wg-allocators/issues/23">https://github.com/rust-lang/wg-allocators/issues/23</a> (should allocators be able to customize the error type?)<br>
2. Propose not to block, and propose a design for <code>CollectionAllocErr</code> that allows both outcomes. (Where it it’s not generic at first, but can be generalized to a generic type that contains a custom allocator-type-specific error.)<br>
3. Propose not to block, and that <code>CollectionAllocErr</code> is not and won’t be generic. <code>try_reserve</code> will simply ignore the custom error value return by the allocator.</p>



<a name="167844221"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167844221" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167844221">(Jun 11 2019 at 12:18)</a>:</h4>
<p>OK those choices seem largely independent of other concerns. It seems like something that could be worth pursuing. Does anyone in the wg want to sponsor the effort (ie make themselves available for questions, reviews, etc)?</p>



<a name="167845058"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167845058" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167845058">(Jun 11 2019 at 12:31)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/48043" target="_blank" title="https://github.com/rust-lang/rust/issues/48043">https://github.com/rust-lang/rust/issues/48043</a> is the place to discuss <code>try_reserve</code></p>



<a name="167846984"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167846984" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167846984">(Jun 11 2019 at 12:57)</a>:</h4>
<p><span class="user-mention" data-user-id="224872">@Ryan Levick</span> I wrote up a proposal <a href="https://github.com/rust-lang/rust/issues/48043#issuecomment-500828346" target="_blank" title="https://github.com/rust-lang/rust/issues/48043#issuecomment-500828346">https://github.com/rust-lang/rust/issues/48043#issuecomment-500828346</a></p>



<a name="167847019"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167847019" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167847019">(Jun 11 2019 at 12:57)</a>:</h4>
<p>I basically picked # 2 above</p>



<a name="167847447"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167847447" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167847447">(Jun 11 2019 at 13:02)</a>:</h4>
<p>Awesome thanks for pushing it forward! Having little context, <a href="https://github.com/rust-lang/rust/issues/2" target="_blank" title="https://github.com/rust-lang/rust/issues/2">#2</a> does sound ideal given its the most flexible and doesn't have any immediatly obvious large tradeoffs</p>



<a name="167847676"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167847676" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167847676">(Jun 11 2019 at 13:04)</a>:</h4>
<p>Not sure how I feel about the name bikesheding. It feels right to open the possibility of having this serve box and potentially other smart pointers in the future but it does open the problem space up more. I wonder how bad it would feel to eventually have a similar error type outside of collections for smart pointers</p>



<a name="167847699"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167847699" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167847699">(Jun 11 2019 at 13:04)</a>:</h4>
<p>(Re-reading through the tracking issue reminded me that it doesn’t have to be an enum, so that makes things easier)</p>



<a name="167847811"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167847811" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167847811">(Jun 11 2019 at 13:06)</a>:</h4>
<p>It would likely be the exact same type, would would feel pretty bad to me. Renaming now sounds easier than introducing a new name later and deprecating the old one after it has been stabilized</p>



<a name="167847899"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167847899" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167847899">(Jun 11 2019 at 13:07)</a>:</h4>
<p>OK can it live in the alloc crate? That seems like an obvious choice</p>



<a name="167847928"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167847928" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167847928">(Jun 11 2019 at 13:07)</a>:</h4>
<p>And why ContainerAllocError and not AllocError?</p>



<a name="167848101"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167848101" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167848101">(Jun 11 2019 at 13:09)</a>:</h4>
<p>We already have <code>AllocErr</code> which is used in the return types of methods of the <code>Alloc</code> trait. This one does not contain a <code>Layout</code>, because the immediate caller already knows what layout it just passed. Making it zero-size allows <code>Result&lt;NonNull&lt;_&gt;, AllocErr&gt;</code> to be pointer-sized.</p>



<a name="167848215"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167848215" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167848215">(Jun 11 2019 at 13:10)</a>:</h4>
<p>We don’t so far export anything other than modules (and macros) at the root of standard library crates. So even in the alloc crate, we need to pick (or make) a module for this to live in</p>



<a name="167848242"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167848242" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167848242">(Jun 11 2019 at 13:11)</a>:</h4>
<p>Maybe the <code>alloc</code> module</p>



<a name="167848251"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167848251" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167848251">(Jun 11 2019 at 13:11)</a>:</h4>
<p>Yea that's what I had in mind</p>



<a name="167848350"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167848350" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167848350">(Jun 11 2019 at 13:12)</a>:</h4>
<p>And the existence of an AllocErr that essentially is the same thing but does not contain layout information is a bit unfortunate. I think putting Container in front doesn't properly specify what is different about this type</p>



<a name="167851703"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167851703" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167851703">(Jun 11 2019 at 13:52)</a>:</h4>
<p>There’s also the capacity-overflow case, where the container didn’t even go as far as calling <code>alloc()</code></p>



<a name="167851711"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167851711" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167851711">(Jun 11 2019 at 13:52)</a>:</h4>
<p>(or <code>realloc()</code>)</p>



<a name="167852407"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167852407" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167852407">(Jun 11 2019 at 14:00)</a>:</h4>
<p>So the two use cases are: an API for an allocator itself. <code>Layout</code> is a parameter of that API, so it doesn’t need to be in the return value. And a fallible method for some other library that happens to do allocation internally. It’s the library that does layout computation. This computation can overflow, but if it doesn’t and the allocation fails, then users want to know the <code>Layout</code>.</p>



<a name="167852528"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167852528" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167852528">(Jun 11 2019 at 14:02)</a>:</h4>
<p>So yes, maybe <code>Container</code> is not the right word. But we do need two different error types. <span class="user-mention" data-user-id="224872">@Ryan Levick</span>, do you have a naming suggestion?</p>



<a name="167854692"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167854692" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tom Phinney <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167854692">(Jun 11 2019 at 14:23)</a>:</h4>
<p><code>AllocErrWithLayout</code> would be self-descriptive, or <code>AllocAndLayoutErr</code> if <code>Err</code> must be the suffix?</p>



<a name="167854904"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167854904" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167854904">(Jun 11 2019 at 14:25)</a>:</h4>
<p>But it <em>sometimes</em> contains a <code>Layout</code></p>



<a name="167855011"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167855011" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167855011">(Jun 11 2019 at 14:26)</a>:</h4>
<p>(Either in one of its own variants by being an enum, or by having an <code>Option&lt;Layout&gt;</code> field)</p>



<a name="167870503"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/failable%20allocators%20and%20collections/near/167870503" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/failable.20allocators.20and.20collections.html#167870503">(Jun 11 2019 at 17:18)</a>:</h4>
<p>That's tough. I don't have any good suggestions. Maybe: <code>AllocationRequestErr</code>?</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>